LAP-IoHT: A Lightweight Authentication Protocol for the Internet of Health Things

The Internet of Health Things (IoHT), which is an extension of the Internet of Things (IoT) in healthcare, has provided a new type of telemedicine approach. In IoHT, wearable sensors are used to collect patient health data, and information is transmitted remotely to doctors who can develop accurate treatment plans and provide timely telemedicine services to patients. However, patient health data are transmitted over a public channel, which means that the privacy and medical data of patients are at significant risk of leakage and can be confronted by serious security problems. We proposed a lightweight authentication protocol known as LAP-IoHT for IoHT environments to overcome the various threats that are currently faced by IoHT. We verified the security of LAP-IoHT using a Real-or-Random model and demonstrated its significant performance advantage by conducting a comparative analysis with other similar protocols for a better adaptation to the IoHT environment.


Introduction
The rapid development of communication technologies has resulted in the extensive application of the Internet of Things (IoT) [1][2][3][4]. By using wireless networks to connect devices and various servers, IoT [5] provides a new means of communication that further enables interaction between virtual environments and the real world. Sensors [6,7] are the most common and versatile IoT devices. Wireless sensor networks (WSNs) [8][9][10] consist of numerous sensors to monitor specific areas and collect data. Hence, sensors and WSNs play an essential role in IoT development. At present, IoT is widely deployed in various applications and environments, such as manufacturing [11], environmental protection [12], smart cities [13,14], and intelligent transportation [15,16]. The rapid increase in the number of IoT devices demonstrates the importance and development potential of IoT, which is gradually improving the quality of life and making intelligent living and digital life possible.
Furthermore, the Internet of Health Things (IoHT) [17,18], which is a subset of IoT, is used extensively in healthcare scenarios [19][20][21]. In IoHT, wearable sensors [22,23] are implanted into the human body or set on body surfaces depending on the disease condition, thereby continuously monitoring the physiological indicators of the patient. These wearable sensors collect real-time data from the human body and transmit them to servers. Doctors can remotely analyze these data in order to provide timely medical services to patients. As the development of the healthcare sector is closely linked to people's lives, IoHT can prevent several chronic diseases, save patient transportation costs, protect the health of healthcare professionals, reduce the possibility of conflicts between doctors and (1) To address the current security issues frequently encountered in healthcare IoT systems, we designed a three-factor IoHT-based protocol that incorporates authentication and key negotiation, thereby guaranteeing privacy and access control. (2) The introduction of biometrics, which protects the anonymity of users with unique information, can provide better user experience and privacy protection. In addition to using common one-way hash functions and simple XOR operations, we adopted asymmetric encryption and decryption in the protocol to provide higher security. (3) Based on a shared ROR model, we performed a formal security analysis to evaluate the security, soundness, and integrity of the session key and protocol. Moreover, the informal security analysis provided strong evidence that the protocol is resistant to currently known security attacks. (4) We conducted a comparative study and analyzed the performance of several protocols of the same type, taking into account the computational cost, time efficiency, and security properties. The results demonstrated that our protocol exhibits a significant performance advantage.
The remainder of this paper is organized as follows: Section 2 describes related work. In Section 3, we outlined the proposed LAP-IoHT protocol. Sections 4 and 5 provide the security analysis and performance evaluation, respectively. Finally, Section 6 concludes the paper.

Related Work
IoT is widely adopted in healthcare monitoring systems. Onasanya et al. [28] proposed an IoT healthcare system for cancer care. Sun et al. [29] developed a medical record search protocol for IoT healthcare to ensure privacy preservation. Zhang et al. [30] proposed an isolation computing technology for cloud-based IoT healthcare. In 2020, Selvaraj et al. [31] reviewed the challenges and opportunities in IoT healthcare systems. Furthermore, several researchers have emphasized security and privacy issues. In 2019, Alassaf et al. [32] simulated the implementation of cryptographic functions for data in IoT healthcare. Kumari et al. [33] described a secure framework for medical systems in 2020. In 2021, Hossien et al. [34] introduced a privacy-preserving architecture for IoT healthcare based on blockchain. Wang et al. [35] proposed privacy preservation in IoT-enabled healthcare systems. Moreover, several authentication protocols are available for IoHT. A summary of the applications of IoT in the medical industry is presented in Table 1. In 2015, Amin et al. [36] argued that elliptic curve cryptography could provide improved security for IoHT, but the protocol was not resistant against offline password-guessing attacks and privileged insider attacks. Challa et al. [37] proposed a three-factor authentication protocol for IoHT in 2018. However, once the sensor node was obtained by a malicious attacker, it broke the security of the protocol [37]. In 2019, Preeti et al. [38] designed a protocol that applied a WSN to IoHT and used a smart card. However, their protocol did not provide perfect forward security or resistance against sensor node capture attacks. Aghili et al. [39] proposed an access control and ownership transfer protocol for IoHT systems. Unfortunately, Amintoosi et al. [40] pointed out that the protocol of Aghili et al. [39] could not provide perfect forward security and was vulnerable to malicious sensor and server spoofing attacks. They also proposed a low-cost protocol for IoHT. In 2019, Gupta et al. [41] proposed a protocol that used wearable medical devices for IoHT to prevent attackers from modifying patient health information. However, Hajian et al. [42] pointed out that this protocol [41] did not protect information against privileged insider attacks, offline password-guessing attacks, and de-synchronization attacks. The proposed protocol of Hajian et al. [42] also could not provide perfect forward security and was vulnerable to session-key disclosure and impersonation attacks. To improve the security of the protocol, Kumar et al. [43] used digital signatures to encrypt the IoHT protocol communication process. Recently, Yu et al. [44] proposed a more realistic application-compliant authentication protocol designed around blockchain and physically unclonable functions while also enhancing mutual authentication between entities. Table 1. A summary of the application of the Internet of Things in the medical industry.

Protocols Advantages Limitations
Amin et al. [36] (  Figure 1 depicts the overall network model of the proposed protocol. This model describes a typical IoHT environment. The architecture includes three entities: users, a gateway, and wearable sensors:

Network Model
(1) Wearable sensors are set on the bodies of patients. They can observe various body indicators, such as the electrocardiogram (ECG), electromyography (EMG), electroencephalogram (EEG), respiratory rate, pulse, blood pressure, blood glucose, and oxygen saturation. These wearable sensors should be registered with a gateway before being deployed to human bodies for precise management. (2) Users are organizations or groups of people who can view the health data of patients.
For example, users may be hospital administrators, doctors, pharmacists, nurses, families of patients, data analysts, and drug trialists. If a person needs to enter the network and view patient medical data, the person must register with the gateway in advance and become a legitimate user with the appropriate authorities. (3) The gateway in our IoHT architecture acts as a trusted server. Prior to entering this network, all wearable sensors and users should register with the gateway. Subsequently, the gateway manages the list of all sensors and legitimate users.
Assume that a user desires to obtain data from a specific wearable sensor. This user transmits a request to the gateway and the gateway forwards this request to the sensor. After receiving the request, the wearable sensor sends the data to the user with the help of the gateway. Since medical data are personal and private, all communications among the users, gateway, and sensors should be confidential. The most straightforward method for achieving this is to encrypt the transmitted data.
The gateway can authenticate users and sensors using the proposed protocol. Moreover, a shared session key is established for each session.

LAP-IoHT
This section presents the proposed LAP-IoHT protocol for IoHT, which consists of three phases: user registration, sensor registration, and login and authentication. The notations and symbols are defined in Table 2.

User Registration Phase
Assume that user U i desires to become a legitimate user. This user must register with GW N. Figure 2 shows the steps that are involved in this phase. The messages are transmitted through a secure channel.
(1) U i prepares his or her own ID i and PW i and unique biometric Bio and selects a random number r 1 . Subsequently, (2) GW N first verifies whether H ID i has already been registered. Thereafter, GW N calculates , Ω i , M} in his or her smart card.

Notations Descriptions
Private key of GWN pbs Public key of SN j pvs Private key of SN j SK Session key T s Time stamp, where s = 1, 2, 3, 4 r 1 , r u , r g , r s Temporary random number Hash function Gen(·)/Rep(·) Fuzzy extractor/reproduction function (2) GW N first verifies whether H ID i has already been registered. Thereafter, GW calculates

Notations Descriptions
Private key of GWN pbs Public key of SN j pvs Private key of SN j SK Session key T s Time stamp, where s = 1,2,3,4 r 1 , r u , r g , r s Temporary random number ⊕ XOR operation Concatenate operation h(·) Hash function Gen(·)/Rep(·) Fuzzy extractor/reproduction function

Sensor Registration Phase
A wearable sensor must also be registered before joining the network. Assume th

Sensor Registration Phase
A wearable sensor must also be registered before joining the network. Assume that sensor SN j desires registration with GW N. Figure 3 depicts the detailed steps involved in this phase. The messages are submitted via a secure channel: (1) SN j sends its identity SID j to GW N.
(2) GW N generates a random number b and calculates the pseudo-identity PID j of SN j , where PID j = h(SID j b). Subsequently, GW N calculates HSID j = h(SID j G j ) and SG = h(HSID j G j ) ⊕ PID j with its own private key G j . GW N also uses an asymmetric encryption system to encrypt PID with the public key of SN j . At this point, GW N calculates L = ENC pbs (PID j ), sends {SG, L} to SN j , and stores {SID j , PID j } in the database.  where PID j = h(SID j b). Subsequently, GW N calculates HSID j = h(S and SG = h(HSID j G j ) ⊕ PID j with its own private key G j . GW N also asymmetric encryption system to encrypt PID with the public key of SN point, GW N calculates L = ENC pbs (PID j ), sends {SG, L} to SN j , and stor PID j } in the database.

Login and Authentication Phase
If U i requires connection to a specific wearable sensor SN j , GW N needs to v legitimacy of the user. Subsequently, U i , GW N, and SN j build a session key to en messages among them. In this phase, several parameters (e.g., M , X UG , X GS , X Gu ) are calculated. Figure 4 illustrates this phase, the details of which are as fol (1) U i inserts his or her smart card into a smart card reader/computer and his or her identity ID i , password PW i , and biometrics Bio. This computer c . Subsequently, it determines wh is equal to M stored in the smart card. If M = M, the computer gen and timestamp T 1 , and calculates (2) GW N first verifies the freshness of T 1 and retrieves the corresponding D 1 own database according to H ID i . Thereafter, GW N calculates . If X UG and the received equal, GW N generates a random number r g and current timestamp T 2 . Subs

Login and Authentication Phase
If U i requires connection to a specific wearable sensor SN j , GW N needs to verify the legitimacy of the user. Subsequently, U i , GW N, and SN j build a session key to encrypt the messages among them. In this phase, several parameters (e.g., M , X UG , X GS , X SG , and X Gu ) are calculated. Figure 4 illustrates this phase, the details of which are as follows: (1) U i inserts his or her smart card into a smart card reader/computer and provides his or her identity ID i , password PW i , and biometrics Bio. This computer calculates (2) GW N first verifies the freshness of T 1 and retrieves the corresponding D 1 from its own database according to H ID i . Thereafter, GW N calculates B 1 = h(D 1 G j ), r u = B 1 ⊕ B 2 , and X UG = h(T 1 r u H ID i B 2 ). If X UG and the received X UG are equal, GW N generates a random number r g and current timestamp T 2 . Subsequently, , and X GS = h(T 2 r u r g SID j B 5 ). Thereafter, GW N transmits {B 4 , B 5 , B 6 , X GS , T 2 } to SN j .
(3) SN j verifies the freshness of T 2 and then obtains PID j by decrypting L with his or her private key pus. Thereafter, SN j calculates , and X GS = h(T 2 r u r g SID j B 5 ). SN J determines whether X GS is the same as the received X GS . If so, SN j generates T 3 , r 3 , and computes B 7 = r s ⊕ h(SG D 1 r g ), X SG = h(T 3 r g r s B 7 SG), and X SU = h(r u r s SID j D 1 ). Finally, SN j calculates the session key SK as h(r u r g r s ). At this point, SN j transmits {B 8 , X SG , X SU , T 3 } to GW N. (4) GW N first verifies the freshness of T 3 , and calculates B 7 = B 8 ⊕ PID j , SG = h(HSID j G j ) ⊕ PID j , and r s = B 7 ⊕ h(SG D 1 r g ). Subsequently, GW N verifies the legitimacy of SN j by determining whether h(T 3 r g r s B 7 SG) is equal to X SG . If they are equal, GW N generates a timestamp T 4 , computes B 9 = D 1 ⊕ B 1 , B 10 = B 9 ⊕ h(H ID i G j ) ⊕ r s , and B 11 = SID j ⊕ h(B 1 r s ), and produces a session key SK = h(r u r g r s ). GW N provides X GU = h(T 4 r u r g B 10 ) for mutual authentications with the user and sends {B 5 , B 10 , B 11 , X GU , X SU , T 4 } to U i . (5) The computer of U i inspects the timestamp from GW N, and computes r s = B 1 ⊕ B 10 ⊕ D 4 and r g = B 5 ⊕ h(D 1 r u ). Thereafter, it calculates X GU and verifies whether X GU = X GU . Subsequently, it calculates X SU = h(r u r s SID j D 1 ), where SID j = B 11 ⊕ h(B 1 r s ). At this time, U i can successfully calculate the session key SK = h(r u r g r s ).
Obviously, U i , GW N, and SN j have the same session key at this point.
Version July 3, 2022 submitted to Journal Not Specified 7 of 16

Security Analysis
This section first describes the capabilities that the attacker A may possess. Subsequently, we demonstrate that our method is secure against different types of attacks. Finally, we use the Real-or-Random (ROR) model to show that our LAP-IoHT protocol is provably secure.

Adversary Model
We consider the well-known Dolev-Yao (DY) adversary model [45] and assume that an attacker A has the following capabilities: (1) A can eavesdrop, block, replay, alter, and delete messages that are sent over a public channel. (2) A can steal the smart card or smart device of a user and obtain the information stored therein. (3) A can capture a sensor node to extract the information stored therein. (4) A can obtain the long-term key of the gateway and acquire the contents stored therein as an internal privileged person.

Replay Attack
In LAP-IoHT, messages that are transmitted via a public channel have timestamps, such as T 1 , T 2 , T 3 , and T 4 . These timestamps ensure the freshness of the messages and resist replay attacks. Moreover, X UG , X GS , X SG , X SU , and X GU include random numbers. Timestamps and random numbers are two effective means of preventing replay attacks. Thus, LAP-IoHT is resistant against replay attacks.

User Impersonation Attack
Assume that A can obtain the private key G j of GW N. Even if A intercepts the parameters T 1 , H ID i , and B 2 via a public channel, A still cannot obtain r u because A cannot obtain B 1 and D 1 . Therefore, A fails to calculate X UG , cannot pass the authentication of GW N, and cannot imitate U i for communication. Thus, LAP-IoHT can effectively resist user impersonation attacks.

Server Impersonation Attack
Suppose that A can obtain a smart card for U i . However, A does not know the value of SID j and the private key G j of the gateway; therefore, A cannot pass the authentication of SN j by computing X GS and cannot successfully imitate the gateway. Hence, our protocol can defend against server impersonation attacks.

Privileged Insider Attack
If A is an insider of GW N, A can obtain H ID i , D 1 , SID j , and PID j , which are stored in the database of GW N. However, A cannot successfully obtain the session key because he or she does not know r u , r g , and r s . Thus, the proposed protocol can defend against privileged insider attacks. Therefore, we can state that the proposed protocol is secure against insider attacks.

Known Session Specific Temporary Information Attack
We assume that the temporary random number r u is obtained using A. If A wishes to calculate the session key SK, three parameters r u , r g , and r s are required. However, A cannot know r g because he or she cannot obtain PID j . Furthermore, A cannot obtain r s . Thus, our protocol is not affected by temporary information leakage.

Stolen Smart Card Attack
A obtains {D 1 , D 3 , D 4 , Ω i , M} stored in the smart card that he or she has stolen. Even if A knows B 2 and D 1 , A cannot obtain B 1 because he or she cannot obtain G j . This implies

Perfect Forward Security
If A knows the G j of the gateway when calculating the random number r u = B 1 ⊕ B 2 , B 2 can intercept the transmitted information and the other parameter B 1 = h(D 1 G j ). G j is already known by A, but as D 1 = h(H ID i N), A cannot obtain N and H ID i and, hence, cannot know D 1 . Since A cannot calculate r u , he or she cannot obtain session key SK. Therefore, our protocol provides perfect forward security.

ROR Security Analysis
The ROR (Real-or-Random) model is a widely used security-proof method. The ROR model can obtain the probability of successfully breaking session key SK through several different game rounds. Therefore, we use the ROR model to perform a formal security analysis to demonstrate the security and accuracy of the protocol.

ROR Model
Our protocol comprises three entities: U i , GW N, and S j . We use Π x U i , Π y GW N , and Π z S j to denote the x-th user, y-th gateway, and z-th sensor nodes, respectively, such that GW N , and Π z S j }. Suppose that attacker A can execute the following queries: Execute(R): When this query is executed, A can intercept the messages that are transmitted among entities U i , GW N, and S j over the public channel.
Send(R, M): By executing this query, A can send message M to R and receive the response message from R.
Hash(String): Through this operation, A can obtain the hash value of a fixed-length string after inputting it.
Corrupt(R): By executing this query, A obtains the private value of an entity, such as long-term key, generated temporary information, or parameters that are stored in a smart card.
Test(R): Assume that A executes this query and can determine the security of the session key by tossing coin C. If C = 1, A obtains the correct session key. Otherwise, A receives a random string.
Theorem 1: In the ROR model, we use Adv P A as a function of the attacker's ability to compromise the protocol through query operations; that is, the probability that A can obtain the session key Adv P A ≤ q 2 h /|H| + q s /2 t−1 |D|, where q h and q s represent the number of times to perform the Hash and Send queries, respectively, |H| and |D| represent the space range and dictionary size corresponding to the hash operation, respectively, and t represents the number of bits of biological information in the protocol.

Security Proof
To prove the accuracy of Theorem 1, we performed four rounds of game GM i (i = 0, 1, 2, 3), where Succ GM i A denotes the probability of the attacker A winning in each round of the game. The details of the game are as follows.
GM 0 : At the beginning of the game, A only needs to determine bit b and does not perform any query operation. Therefore, we can obtain GM 1 : GM 1 performs a wiretap operation on top of GM 0 . In this round, A can only steal messages that are transmitted on the common channels {HID i , B 2 , X UG , T 1 }, {B 4 , B 5 , B 6 , X GS , T 2 }, {B 8 , X SG , X SU , T 3 }, and {B 5 , B 10 , B 11 , X GU , X SU , T 4 }. A cannot execute the Test queries to obtain the session key SK = h(r u r g r s ) during communication because the values of the random numbers r u , r g , and r s cannot be obtained based only on the information in the common channels. Therefore, the probability of A winning the game after performing an Execute query is equal to GM 0 .

Pr[Succ
GM 2 : GM 2 is the third round of the game, in which the Hash query and Send operation have already occurred in GM 1 . During the game, forgery is not possible because B 4 , X UG , B 4 , B 5 , X GS , B 1 1, X SG , X SU , and X GU are encrypted using hash functions. Moreover, the important parameters r u , r g , and r s , which constitute the session key, are random in all sessions and do not cause hash conflicts. Thus, according to the birthday paradox, we obtain GM 3 : In this round, the Corrupt query is executed and the attacker A can obtain the private value of an entity, such as {SG, L}, {D 1 , D 3 , D 4 , Ω i , M}, or {SID j , PID j , H ID i , D 1 }. Moreover, A attempts to guess ID i and PW i ; however, even if A can successfully guess ID i and PW i simultaneously, he or she still cannot obtain the random number r u . Since , and the probability of the biometric being estimated is 1/2 t , A cannot obtain the biological eigenvalue Bio. If A can only enter the code a finite number of times, we know that Since A can only win the game if the correct bit b is guessed, we obtain Using Equations (1)-(5) above, we obtain Ultimately, we can obtain Adv P A ≤ q 2 h /|H| + q s /2 t−1 |D|.

Security Comparisons
We compare LAP-IoHT with other related protocols with similar architectures, such as those of Kumar et al. [43], Yu et al. [44], Amin et al. [36], Challa et al. [37], Aghili et al. [39], and Preeti et al. [38]. We set the following representations: A1: resist replay attack; A2: resist impersonation attack; A3: resist privileged insider attack; A4: perfect forward security; A5: resist known session specific temporary information attack; A6: resist stolen smart card attack; A7: resist offline password guessing attack; A8: resist sensor node capture attack; A9: resist de-synchronization attack; A10: resist session key disclosure attack. "Y" indicates that the protocol is invulnerable to this attack, and "N" indicates that the protocol is vulnerable to this attack. The results in Table 3 demonstrate that, with the continual development of technology and various attack methods, the other related protocols will be affected by the above attacks. Compared to these protocols, our method exhibits better security and sufficient advantages in resisting the above attacks to guarantee the security of communication sessions.

Performance Comparison
In this section, we evaluate the performance of the proposed LAP-IoHT protocol by performing comparisons with other protocols, such as those proposed by Kumar et al. [43], Yu et al. [44], Amin et al. [36], Challa et al. [37], Aghili et al. [39], and Preeti et al. [38], in terms of the computation time and communication cost.
We used different devices to obtain the computation time and communication cost required for the certification stage in the performance comparison. We used a mobile phone, laptop computer, and desktop computer to simulate the user, gateway, and sensor nodes, respectively. The relevant parameters for the three devices are listed in Table 4. Table 5 presents the times required by different devices to perform certain operations. T H denotes the time required to perform a single hash function operation, T SED denotes the time required to perform a single symmetric encryption or decryption operation, T FE denotes the time required to perform a single fuzzy extraction operation, T ASED denotes the time required to perform a single asymmetric encryption or decryption operation, T S denotes the time required to execute the digital signature operation, and T PM denotes the time required to perform an elliptic curve point multiplication operation. As the communication times required by the connection and XOR operations are insignificant compared to the other operations, these can be ignored. Table 6 presents a comparison of the communication times of our proposed protocol and other similar protocols. Several communication costs arise in the communication process, and asymmetric encryption or decryption has an enormous overhead of 1024 bits. The length required for the elliptic curve point multiplication operation is 320 bits; the length of each block for symmetric encryption or decryption is 256 bits; the hash values and random numbers all have similar lengths of 160 bits; the identity, password, and biometrics are all 128 bits in length; the timestamps require a length of 32 bits. In Table 7, we compare the communication overheads of multiple protocols to determine the specific communication cost.

Computation Time
We use three devices to determine the computation time and communication cost. The times required to perform elliptic curve point multiplication, symmetric encryption/decryption, asymmetric encryption/decryption, single fuzzy extraction, and hash functions vary on different devices. Furthermore, the computation times required for the connection and XOR operations are insignificant compared to the other operations; thus, we ignore these in our evaluation.
The computation times of the proposed protocol and other similar protocols are listed in Table 6. Table 6 shows the computation costs of all protocols. The most time-consuming protocol is the protocol proposed by Kumar et al. [43], which includes elliptic curve point multiplication and digital signature operations. The protocol proposed by Yu et al. [44] is the least time consuming. Although our proposed protocol includes fuzzy extraction and asymmetric operations in the login and authentication processes, its computation time is relatively short.

Communication Cost
We assume that the output of asymmetric encryption/decryption is 1024 bits; the length required for the elliptic curve point multiplication operation is 320 bits; each block for symmetric encryption/decryption is 256 bits; the hashed value and random number are 160 bits; the identity, password, and biometrics are all 128 bits in length; the timestamps require a length of 32 bits.

Conclusions
Internet of Health Things (IoHT), which promotes intelligent healthcare, plays a pivotal role in the future e-healthcare environment. Due to its high sensitivity, the health data transmitted through a public channel should be protected from unauthorized access. This means that an authentication protocol is essential. This paper presented a more secure and reliable authentication protocol called LAP-IoHT for the Internet of Health Things. LAP-IoHT provides mutual authentication among users, sensors, and a gateway over a public channel. Moreover, a user and a sensor can establish a common session key after a protocol run. By using the ROR model and performing an informal analysis, it was proven that LAP-IoHT has adequate security and reliability as well as sufficient ability to resist various attacks. Furthermore, we compared LAP-IoHT with related protocols and found that our protocol is at the mid-to-upstream level in terms of time and communication costs, exhibiting a significant performance advantage. In summary, the proposed protocol offers specific practical value in the current environment and has more robust adaptability relative to the future development of IoHT.

Conflicts of Interest:
The authors declare no conflict of interest.